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for lotfer division FOBTBAN classes in a university were investigated* 
Samples of these programs vere also benchmarked on a larger central 
site computer and two minicomputer systems. It was concluded that a 
carefully chosen minicomputer system could offer service at least the 
equivalent of the central systemt and that certain aspects could be 
distinctly better. (Author/SK) 
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ABSTRACT 

Thf& chnracterlfiClcs of Jobs that constitute the mix for lower division 
FORTRAN classes in a university are investigated. Samples of these programs 
are also '^enchmorked on a large central site computer and two minicomputer 
systems. The conclusion of this study is that a carefully chosen minicomputer 
system could offer service at least the equivalent of the service provided 
by the central site system, and that certain aspects of this service could be 
distinctly better. 
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In a tine of constant (or decreasing) enrollment In many universities, 
one Bight not expect enrollaent for a given set of courses to increase sig- 
nificantly. The toiversity of Colorado has been operating at an Imposed 
enrollment of 20,000 students since the Fall Semester of 1972; nevertheless, 
all of the lower division computer classes Ua^e been subject to higher enroll- 
ments in corresponding academic terms from year-to-year. In particular, the 
lower divisi <n FORTRAN class enrollment for the 1971-1972 academic year was 
765 students; for the 1972-1973 academic year, 874 students; and the 1973-1974 
academic year enrollment figure is 950 students.* Each of these students write 
and test an average of twelve programs per year, with each program requiring 
about 5 debugging runs. This large (and growing) novice student job load 
requires a significant amount of computer centar resource in terms of operator 
time, line printer and card reader use, keypunch, etc. It is our contention, 
however, that an insignificant amount of processor time is required to support 
this mix. 

A few critical characteristics of lower division FORTRAN programs will 
be explored in some depth later in this paper; we now only briefly define the 



* Otjpartment of Computer Science lower division FORTRAN courses are: 
Cowputer Science 162 - Digital Computer Programming 

Computer Science 201 - Introduction to Computer Scieice for Scientists and 

Engineers 

Computes- Science 203 - Introduction to Con^uter Scie-ace for Liberal Arts 

Majors 

From Fali, 1971 through Fall, 1972, Computer Science for Business Malors 
was also a FORTRAN course. 
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character of a typical, program from this mix. The average job includes a 
call to the compiler, possibly followed by loading and execution. The total 
amount of central processor time, on the average, is less than one secondi 
a portion of this processing requirement is absorbad in compilation and loading 
The programming assignments become more complex late in the academic term, 
requiring more run time, (the average central processor time is still less than 
two seconds). The reasons for this light processor requirement are concerned 
with the assignnents; iterative calculations are generally contrived and 
converge rapidly, or the error bound is very generous. (We should also point 
out that error bounds are never seriously considered in the lower division 
programming classes.). On the other hand, the average program from this mix is 
composed of about 30 cards, and prodxtces about 140 lines of output. It is 
easy to recognize the imbalance between the time required for printing and 
the time required for processing. 

At the University of Colorado, as in many universities, lower division 
programming courses use the central site computer, in this case a pair of 
Control Data 6400 systems. This particular Install tion supports both batch 
and Interactive processing, although the Introductory students use only the 
batch processing facility. In addition to the educational load, the system 
is subjected to a variety of other tasks; it must support research projects 
involving large numerical computations; It is likely that administrative data 
processing may be done on the machine, etc. This wide range of responsibility 
can only be covered at the expense of individual subsets of the set oZ all 
users. As the work load subjected to the system Increases, turnaround time 
for individual Jobs may be expected to Increase. Features of the system that 
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night be oriented toward the novice programmer may be sacrificed for the good 
of the community. For example, optimizing compilers may replace those that 
produce object code more rapidly; run time error messages may be terse and 
unmterpretable; the Job control language may be so complex as to make a simple 
compile-and-execute sequence a formidable task; the job accounting algorithms 
may be unrealistic. 

One alternative to central site computing is the use of a dedicated mini- 
computer system for lower division programming students. This situation can 
Improve the cost-effectiveness of computation by using relatively inexpensive 
processing power to achieve a closer match between job input/output time and 
the processor utilisation. However the use of miniccoputer systems may 
actually create a situation in which the bottleneck for throughput is the 
processor, i.e,, compilation, loading, and execution of a job may actually 
require more time than reading the deck of cards or printing the resulting 
listing. 

Nevertheless, we contend that this alternative can be superior to the use 
of a central site system if the minicomputer system is carefully chosen. In 
the remainder of this paper we shall support this contention by discussing a 
Job mix analysis done on lower division FORTRAN programs executed on the Control 
Data 6400 batch system. We shall also discuss a more cost-effective method of 
offering the same service with the added benefit of minimal hands-on experience. 
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JOB LOAD ANALYSIS 

A characterization of the lower division FORTRAN job load, for the 
purpose of this study, is primarily concerned with indicators of I/O tine 
and processor utilization. It is desirable to obtain a quantification of the 
expected nuober of Input cards for a program, the number of lines to be printed, 
and the amount of processor time spent in satisfying computational needs of 
the average program, as well as corresponding maximum loads* It 
might appear that we should also be Interested in the mix of machine instructions 
used during program execution, so that comparisons between large system exe- 
cution and minicomputer executions of the same programs could be made. Some 
simple benchmark programs illustrate that this Is not necessary. 

An interesting characteristic of a job run on the central site computer 
would be the expected actual turnaround time, although we have not been able 
to obtain accurate quantification of this measure of performance. We would 
also like to obtain tnxe job costs, although this, too, is difficult tn obtain, 
due to the somewhat artificial educational computer time rates that usually 
exist in this type of environment. 

To achieve the goals for load characterization, we used two standard 
mcnitorlng tools [2]. The system accounting log is exploited to obtain a 
reasonably conclusive set of data concerning I/O characterisation, central 
processor times, accounting charges, and throueihput requirements. Next home- 
work assignments that constitute the mix were written and benchmarked on the 
Control Data 6400 system. The programs were then tested on two available mini- 
computer systems to compare execution times. 
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Accounting Log Analysis 

All student jobs that axe executed on the Control Data 6400 system at 
the Ublversity of Colorado must supply accounting information designating a 
"user number" and a "subaccount n^.'mber". Each course is assigned a user 
number, and each student is assigned his own subaccount number* Thus the 
accounting system allows job charges to be made directly to the individual 
student subaccount* This accounting procedure proves to be useful in associa- 
ting monitoring information with an individual, as will be discussed below* 

£ach job executed on the system produces a trace of messages for accounting 
purpo£4«s, as well as operator information wd a list of control cards* This 
extended accounting log, or dayfile, ha3 been shown to be quite useful for 
analyzing machine performance [1, 4j. However, the volume of Information 
written to the dayfile precludes the possibility of saving any significant 
number of past records* The University of Colorado Computing Center has 
recognized this problem, and has taken measures to preserve certain items of 
information from the system dayfile for long periods of time [3]. The process 
is to perform an analysis of the system dayfile, gathering a set of character- 
istics for a job, condensing these characteristics to a 136 character string, 
and saving the resulting strings on a magnetic tape file called the Job Master 
File . Taole 1 summarizes the pertinent information contained in a record 
on the Job liaater File* The practice of producing this condensed file was 
Initiated in January, 1972, and thus all Information (shown in Table 1) for 
each job executed on the system since that time is available for analysis. It 
is this Job Master File that we have used to obtain information about the job 
load caused by FORTRAN programs* 
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The analysis program utlXlzes the user number field to recognize 
applicable records from the Job Master File. The subaccount field is used tu 
distinguish between jobs submitted by the various students enrolled In any 
given class. The following Illustrations of data correspond to the set of 
student programs for Computer Science 201, "Introduction to Computer Science 
for Scientists and Engineers" for the Spring Semester (approximately January 
15 through May 15) of 1973. Data gathered for other courses and time periods 
is typefled by this particular saaple. 

In the following presentations, the histograms are for the job mix over 
the entire semester and we also present some histograms for the month of May, 
which represents the maximum demand placed on the system by the C.S. 201 
students. The oaximum demand month is analyzed since it is this load that 
will place the highest demand on the dedicated minicomputer (i.e., it is the 
"worst case" load). 

During the Spring Semester of 1973 there were 18164 jobs submitted under 
the C.S. 201 user number. There were 287 students enrolled in the course 
approximately two weeks after the term began, hence each student submitted 
an average of 63.3 jobs for the semester. In the Job Master File analysis 
program, we compute the mean number of times that a subaccount number (i.e. , 
an individual student account number) appeared in any given day. This measure 
was deemed worth obtaining, since our experience (and Teaching Assistants) told 
us that students often did their entire assigimient in one day. The mean varisd 
from 2.6 jobs/day for each student in January to 5.0 jobs/day for each student 
in May, with a mean over the entire semester of 3.6 Jobs/day. 
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The batch system spools card Images onto the disk for subsequent memory 
and processor assignment. Disk space Is allocated to each Job In 64 word 
(6A0 character) units. The Job Master File records this sector allocation 
rather than the actual number of cards read for each Job, and It Is that 
measure that Is given here. Observations " indicate that batch Jobs require 
at least three sectors, i.e., there is a two sector overhead figure added 
into each Job allocation.* Thus, for 80 column card input, the nuniber of 
cards in i sectors is 8(1-3) + 4, where 4 is the expected number of cards in 
the last sector. 

Figure 1 is a histogram of the number of input sectors allocated per Job, 
e.g., about 13% of the 18164 Jobs (2326) were allocated more than three sectors 
and less than or equal to 4 sectors. The arithmetic mean number of disk 
sectors allocated for card images was 184.8; the histogram indicates a median 
value of about 6 sectors/Job. The explanation for this difference is that 
a small number of Jobs, 65, were allocated more than 26 sectors, and have 
biased the mean value substantially. In our characterization of the typical 
Job we shall use the median value; a sector count of 6 is equivalent to about 
30 cards per Job. This number of cards Includes control cards, program, and 
data. 

Figure 2 shows the statistics for disk sectors used to hold the input 
stream for Jobs submitted during the month of May. Again we note an inflated 
mean value and a median value of about 6 sectors. 

The output 8ps>oling process again uses 640 character disk sectors to hold 
line printer Images, although a packed format is used for the representation 
of a line. Our investigation into the average number of characters per line 

*19 Jobs in the sample period were allocated less than or equal to 1 sector; 
this inconsistency is caused by Interact l\e Jobs on the student account 
number, probably entered by the instructor. 
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indicates that a line is about 50 characteics long* This observation agrees 



Figure 3 indicates our finding over the entire semester, and Figure 4 
gives the corresponding results for the month of May. The mean value for 
output sector allocation of 13.9, again, is biased by a few jobs with an 
inordinately high allocation of output sectors (33 Jobs were allocated more 
than 150 sectors for output). However, the median value is close to the 
calculated arithmetic m^^an, compared to an expected number of lines per job 
of 178. The corresponding mean for May was 19 sectors, (243 lines) prompting 
Figure 5 which shows the mean number of output sectors allocated to each job 
for each month in the sample period. The conclusion is that the amount of 
output produced by a typical job is sensitive to the point in the semester; 
a^ similar analys is indi cates that thejiimber_of_cards is relatively constant 
over the same period of time. 

A measure of the amount of time that the job competes for the processor 
is the amount of central processor time charged to the job. This measure 
ignores the amount of I/O, particularly in the Control Data 6400 with its 
peripheral processors. In Figure 6, thd histogram for central processor time 
is given. Note that 88.5% of all Jobs submitted during the semester required 
less than or equal to one second of central processor time. This processor 
charge includes compilation, loading, and execution. Almost 95» of the jobs 

* This work was done by C. J. Brauch, Assistant Director, University cf 
Colorado Computing Center. 



with an independent study carried out by the Computing Center.* With t'lis 
in mind, the expected number of lines for j sectors is 
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/sector J ^ ^ a J 

/ll^l — d sectors ■ 12.8 j lines. 
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require less than two seconds and almost all of the reioalnlng jobs ran to 
tlffie Halt expiration, as might be expected in an introductory programming 
course. The mean central processor time for the entire semester was 1.0 
seconds • while the mean central processor times for the individual months were 
0.25 seconds, 0.60 seconds, 0.67 seconds, 0.93 seconds, and 1.7 seconds for 
the respective months of January through May. The histogram for processor 
time during the month of May does not differ substantially from Figure 6, 
although the mean has increased. 

Data was gathered and analyzed to represent the amount of time that a 
job was resident either in an input/output queue, or in competition for central 
processor and disk. From practical observation of computer center operation, 
these results were rejected as meaningless for this study. The average amount 
of "queue-to-queue" time for our class of jobs was only 14 seconds i due to 
the process by which job decks dre submitted, run, and output returned to 
the user, the "actual turnaround time" is closer to 15 minutes to a half 
hour. Thus we could not justify using these figures to reflect a turnaround 
figure that represented true service to the user. 

The accounting algorithm used to compute dollar charges for a job uses 
the parameters: average amount of memory allocates, central processor time, 
mass storage transfers, card sectors allocated, and output sectors allocated. 
The exact coefficients for these parameters have varied with the three 
academic years we have mentioned, and with certain other factors such as remote 
job entry site. Nevertheless, we did monitor the job dollar charges to get 
an indicator of the way in which our educational computer time budget is spent. 
Figure 7 is a histogram of dollar charge per job, for the 18164 jobs. The 
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meca cost was about 34C, for a total allocation of $6257.92 for the 
semester (this figure was obtained from billing invoices, and agrees with our 
monitored data) . The resulting dollar cost per student for the term was 
$21.80 for computer time. Considering the combination of all lower division 
FORTRAN classes, the allocation amounted to $7190. or about $18.80 per student 
Cos-respondlng charges for the fall semester (under the same charging algorithm) 
were $6578.28 total, »r $17.40 per student. Bot!* the previous year (1971-72 
academic year) and the following year saw higher charging rates. The total 
amount of money spent on the lower division FORTRaJ computer time amounted to 
$13768.73 for the 1972-1973 academic year (9 months). 

A final conclusion about the data gathered from the Job Master Pile is 
concerned with input-process-output overlap times. Using the mean values 
for processor time and output lines and the median value for cards read, we 
can calculate card reader and line printer rates required to achieve a 
maximum overlap of utilization time. Assuming one second of processor time 
(utilized in about 2 seconds of real time) the card reader must read 30 cards 
and the line printer must print 180 lines in the corresponding real time 
period. Thus the card reader must operate at a constant 9000 cards per minute 
and the line printer (ignoring page eject time) must operate at a constant 
5400 line per minute to keep up with the processor. 
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The Benchmark Tests 

This portloa o£ the study was necessary In order to obtain an understanding 
of processor requirements of the FORTR^ programs on some typical minicomputer 
systems. Four programolng assignments were chosen from the lower division 
FORTRAN course work; the assignments varied from the Initial assignment to 
the final assignment for the academic semester* These assignments were then 
programmed and tested on the Control Data 6400 batch system In order to 
compare these properties with the data obtained from the Job Master File 
analysis* The accounting log provides the amount of central processor time 
charged to the job for compilation and for the load and execute phase of the 
Job. The time of day in seconds is also available from this log, thus we 
have a climsy estimate of real time requirements* The amount of real tine 
required for processing never exceeded two seconds for any single phase of 
Job execution, even though the Job was serviced in a multlprograamlng 
environment* 

The four programs were then tested on a "large minicomputer" system 
considered by some to be a "midl-computer"; we shall call this computer X* 
Average instruction execution times and memory cycle time are not relevant 
here (as will be seen below), since the majority of processor time is spent 
in the compiler and loader. This system also printed each line on the line 
printer after compilation of that statement; this tends to have a detrimental 
effect on the amount of time required to compile the code* 

Finally, three of the four programs were tested on another classic mini* 
computer (which we shall call Y) which has gained a reputation for inefficient 
software* This system compiled the code with no listing until the compilation 
process was complete* 
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Tbe four test programs are described below, and the benchmark findings 
are recorded In Table 2* 

The first test program Is essentially a keypunching assignment; It consists 
of eight cards containing FOBZRAN statements and four job control cards. This 
program produced about 80 lines of output spread over four pages. Including 
twenty lines on a banner page, two pages of listing, and an additional page 
with 20 lines of accounting Information and control card Information 

The second test program would typically have been assigned In the second 
month of the course. The student Is given a crude definition of a prime ntmber, 
and he Is asked to generate the primes that are less than or equal to twenty. 
This program was consciously written to look like code produced by a novice 
programmer, and contains three levels of nested loops. Our test version was 
composed of 18 FORTRAN cards and 4 control cards, and produced 95 lines of 
output on the central site machine. 

Ixr^tam number 3 would be assigned near the middle of the course, and 
Is an output formatting exercise. The deck contains 30 FORTRAN statements, 
4 control cards, and one data card; the output consists of about 160 lines 
Including the 40 lines of banner and accounting Information. 

The last program Is a simulation of a random walk on a 30 x 40 grid, with 
the marker Initially placed In the center of the grid. The program was to 
execute until the marker exited successfully "through a door" or unsuccessfully 
"through a wall". The program that executed on the Control Data 6400 had 59 
FORTRAN cards, 4 control cards, and one data card. There were about 170 
lines of output. The code used a random number generator which was not 
Immediately available on either of the minicomputers, thus there Is no execution 
time on mlnlconqputer X, and no test of the program on minicomputer 
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The data in Table 2 indicates the compiler on minicomputer X is sub- 
stantially faster than the compiler for minicomputer Y. It is also apparent 
that FORTRAN programs that are larger than, say» 100 cards should not be 
compiled repeatedly on these systems due to the excessive compile time. 
The load times are relatively constant for each minicomputer » i.e. X loads 
in about 12-13 seconds and Y loads in about 35 seconds. It is likely that 
disk transfer rates and library sizes determine these times. With the 
exception of the execution of TEST3 on minicomputer X» all of the execution 
times are insignificant when compared with compile and load times. We are 
unable to explain the inordinately large execution time for TEST3 on X. 

A similar benchmark test was done on a third minicomputer system with 
a different set of programs.* The first program tested evaluated a 10 x 10 
determinant with floating point numbers. Gary reports that the program 
consisted of 113 cards » required 7 seconds to coo^ile (without listing), 15 
seconds to load» and less than one second to execute. He also benchmarked a 
program to compute. the greatest common denominator of two integers. This 
program required 25 cards » compiled without a listing in 5 seconds » and again 
executed. in less than one second. 



John M. Gary, Department of Computer Science, University of Colorado. 
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A Dedicated Mlnlconputer System 

We ave now ready to consider the {Plausibility of supporting the lower 
division FORIBAM progr&amlng students on a minicomputer system.. The primary 
consideration Involved here are those of cost and efficiency. The proposed 
system should use an average budget of less than $15000/year if it is to be 
cost competetive with the existing central site computer system. (It is 
assumed that the system is used to support no other C0j:nutsr science course* 
Vhere the total con^uter time budget is about $50000/year.) The system must 
provide good service to a minimum of 500 students per «eek» with growth 
possibilities to 750 students per week. Each student is expected to submit about 
5 jobs per week (i.e. 63.3 j obs /semester) , thus the minimum numbe^^ of jobs per v^ 
is 2500 » and the maximum is 3750 Jobs per week. If these goals are met* the 
system can offer approximately the same service as the central site system. 
In addition* it Is desirable that the dedicated system handle this load in 
a forty hour week» offering actual turnaround tine approaching one minute. 
It is also desirable that each student be given the opportunity to enter 
his deck of cards into the card reader and burst his listing from the line 
printer. Operating in this mode* a dedicated system offers nearly instant 
batch turnaround to small groups of studrats using the machine in a given time 
period. Each student is also provided with a minimum degree of hands-on 
experience. It is this set of factors that weighs heavily toward a dedicated 
minicoB^uter system. 

The Job Kaster File analysis indicates that a typical user progrsm 
(during the course of the semester) is composed of about 30 cards and produces 
about 180 lines of output (including 40 lines of the banner page and accounting 
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Information). The execution tine of the program is insignificant. During 

peak demand periods near the end of the semester, the typical job may consist 

of about 36 cards and produce about 240 lines of output. 

Taking the Job load as a requirement on the system, we can estimate 

the required card reader rate, line printer rate, and processor throushput; 

Assuming that the system is in operation 40 hours per week, and that e&<:h 

student requires an average of 5 jobs per week, we obtain 

Number of jobs/week ■ N . ■ (Number of students/waek) x 5 

N N . 

Number of Jobs/minute - N , - -rr^ 

minute 2400 

Card reader rate for semester "OR - 30 N 

ave minute 

Card reader rate for peak period - CR ■ 36 N.^ ^ 

max minute 

Line printer rate for the semester ■ LP. ■ 140 N . ^ 

ave minute 

Line printer rate for peak period ■ If „ - 200 N . ^ 

max minute 

Here we ignore page eject times and the time required to remove an individual 
listing from the line printer. We also assume that a barAer page and ex* 
tensive accounting information is not printed. 

To maximize resource overlap between the card reader » processor, and 
line printer operation, each Job must be completely serviced by the processor 
(i.e. spooled in, scheduled, computed, loaded, executed, and spooled out) 
in 

seconds. 



^minute 



Table 3 suaoarizes these required service rates for various student loads 
considering average loads for the entire semester and peak loacis for the end 
of the semester. The assumptions used here are: 
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— The character o£ individual programs £rom semeater-to-semQater la 
atatlc 

— No banner page ,nor extensive account^'ng log la to be printed 

— The card reader input rate is greater than or equal to the service 
rate o£ the system 

— Page eject time is negligible 

During the fall semester of 1973, 513 students were enrolled in the lower 
division FORTRAil classes. From Table 3, it can be seen that a modest mlnl- 
ccmputer system could handle the peak load, allowing about one minute of 
processor time for compilation, loading, etc. Furthermore, a very slow card 

i 

reader is adequate, (it must read cards at a rate of about 40 cards/minute), 
and any faster card reader would create the need for substantial (infinite) 
disk space for job spooling. If the system were; equipped with a single line 
printer which operated at a rate in the excess of 210 lines/minute, the printer 
could adequately handle the job load. 

Mote that the portion of the machine that must be drastically upgraded 
for Increasing job load is the processor itself, provided that a reasonable 
card reader (say 75-100 cards per minute) and line printer (say 300 lines 
per minute) are initially configured into the machine. Recall that the 
major portion of processor time for the benchmark programs was employed in 
the loader; it is conceivable that as the current job load grows upward, 
advanced (graduate) students could be involved in improving both the compiler 
and loader efficiency in order to meet the processor requirement. Of course 
a better solution is to initially obtain a minicomputer with adequate soft- 
ware. 
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SUMMARY 

In this peper we have dlacusaed the job load Impoeed on a central 
site computer syetem by the lower division FORTRAN prograanning students* 
In particular, the number o£ Jobs subsdtted for computer service was ob- 
tained* and the expected nunber of Jobs per atudent was calculated. A 
typical Job profile was derivedi with respect to the number of cards in 
the Job, the number of lines of output produced by the Job, and an indicator 
of the processor requirement for three systems. Using this data, we have 
speculated a configuration of a minicomputer system that would handle the 
current Job load as well as allowing for growth to a load that is 1*5 times 
the size of the current load. The main conclusion, then. Is that a dedicated 
miniconputer can handle the growing load caused by lower division FORTRAN 
programing students, and that a careful choice of th(» system can provide 
an excess of processor resource which qould be used for other purposes* 
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Job Master File Format 



(Some Items of information that actually appear on a job description record 

are omitted here for brevity*) 

1-. Subaccount number 

2. User niimber 

3. Ntmber of tapes assigned to the Job ' 

4. Priority of the job 

5. Job name and identification 

6. Batch or interactive job indicator 
1 7. Day of the month 

d. Number of card sectors read 

9. Nuaiber of line sectors printed 

10* Number of microfilm sectors printed 

11. NiBiber of card sectors punched 

12. Central processor time (in tenths of seconds) 

13. Mass storage sector reads/writes 
14* Mag tape sector reads/writes 

15* Time the job spent in the input/output queties and competing for a 
control point ("Internal turnaround time") 

16. Average amount of memory allocated. 

17. Accounting dollar charge. 



Table 1 
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BEST COPY AY W 



Greater 
Than 



1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
12 
14 
16 
18 
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MEAN VALUE OF OUTPUT SECTORS /JOB BY MONTH 
FIGURE 5 
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ACCOUNTING CHARGE IN CENTS - SEMESTER 
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